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(54) Title: Mli'I I lOD FOR STORING XML-FORMAT INFORMATION OBJECTS IN A RELATIONAL DATABASE 

(54) Tilre : PROCEDE DE STOCK AGE DOBJETS INFORMATIONNELS AU FORMAT XML DANS UNE BASE DE DON- 
I Nlil-S RELATIONNELLE 

j (57) Abstract: The invention concerns a 

: r . S method for storing information objects or 

1 ' .. Rfaea V' objects (5) in a relational database (2) stored 

in a server computer ( 1 ), the relational database 
(2) consisting of tables, each formed by a 
table of single data sets having the same data 
structure in a common table, each single data 
being designated by a single identifier in said 
table, an object (6) consisting of one or several 
single data capable of being stored in a table of 
the database (2), and/or one or several objects 
nested in said object. The nesting tan be 
produced on any number of levels to produce 
an object (6), a nested object or a single 
data said to be locally in fixed number if it 
appears exactly once in the object immediately 
containing it and said to be locally in variable 
number otherwise. A single data occurring at 
a particular level of said object (6) is said to be 
globally in fixed number if it is locally fixed 
and all the objects containing it are in fixed 
number, a single data occurring at a particular 
level of said object is said to be invariable 
number if it is locally in variable number or if 
" anv one of the objects containing it is locally in variable number. The data globally in fixed number of an object to be stored (6) 
J arc stored in a main data set (31 ) stored in a main table (3) of the database (2). The single data globally in variable number of said 
" object to be stored (6) arc stored in one or several auxiliary tables (4, 5, 7) of the database (2). When they exist, the single data 
! glohally in variable number of said objects (6) are stored in a single auxiliary table (7) of the database. The method create one or 
5 several sets of auxiliary data sets (71) to store single data globally in variable number in the single auxiliary table (7). 

\ (57) Abrege : Proccde de slockage d'objets informalionnels ou objets (6), dans une base de donnees relationnelle (2) stockee dans 
s un ordinatcur scrvcur ( 1 ), la base de donnees relationnelle (2) etant constituee de tables, chacune constituee d'un tableau d'ensembles 
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la meme structure de donnees dans une meme table, chaque donnee simple d'une table est designee par un identifiant unique dans 
ladite table, un objet (6) etant constitue d' une ou plusieurs donnees simples pouvant etre stockees dans une table de la base de donnees 
(2), et/ou d'un ou plusieurs objets emboftes dans ledit objet. L'emboJtemenl peut etre realise sur un nombre quelconque de niveaux 
pour realiser un objet (6), un objet emboite ou une donnee simple etant dit localement en nombre fixe s'il ou elle apparait exactement 
une fois dans 1'objet le ou la contenant immediatement et efant dit localement en nombre variable dans le cas contraire. Une donnee 
simple apparaissant a un niveau quelconque dudit objet (6) est dite globalement en nombre fixe si elle est localement en nombre fixe 
et si tous les objets la contenant sont localement en nombre fixe, une donnee simple apparaissant a un niveau quelconque dudit objet 
(6) est dite globalement en nombre variable si elle est localement en nombre variable ou si l'un quelconque des objets la contenant est 
localement en nombre variable. Les donnees globalement en nombre fixe d'un objet a stocker (6) sont stockees dans un ensemble de 
donnees principal (31) stocke dans une table principale (3) de la base de donnees (2). Les donnees simples globalement en nombre 
variable dudit objet a stocker (6) sont stockees dans une ou plusieurs tables annexes (4, 5, 7) de la base de donnees (2). Lorsqu'elles 
existent, les donnees simples globalement en nombre variable desdits objets (6) sont stockees dans une unique table annexe (7) de la 
base de donnees, le precede cree un ou plusieurs ensembles de donnees annexes (71) pour stocker les donnees simples globalement 
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PROCEDE DE STOCKAGE D'OBJETS INFORMATIONNELS AU FORMAT 
XML DANS UNE BASE DE DONNEES RELATIONNELLE 

La presente invention a pour objet les process de stockage d'objets 
informationnels, ou objets, dans un systeme informatique, et plus particulierement, 
5 un precede de stockage, dans une base de donnees relationnelle traditionnelle, 
d'objets au format extended Markup Language, ou XML, du consortium Internet 
World Wide Web, ou W3C. 

Les systemes de stockage de donnees sont bien connus dans les techniques 
de traitement de l'information, et de plus en plus frequemment, ils mettent en ceuvre 
1 0 des systemes de gestion de bases de donnees relationnelles. 

Ces systemes sont bien adaptes au stockage de donnees comportant des 
parties en nombre fixe et des parties en nombre variable, les parties en nombre fixe 
etant stockees dans une table principale et les parties en nombre variable etant 
chacune stockees dans une table annexe de la base de donnees. En general, ces 
1 5 systemes permettent en outre de cascader les donnees en nombre variable, c'est-a-dire 
que chaque ensemble ou enregistrement de donnees en nombre variable peut €tre k 
) son tour associe a d'autres donnees en nombre variable. En outre, ces systemes de 

gestion de base de donnees offrent habiruellement des possibilites d'interrogation 
sophistiquee, et de bonnes performances, meme sous forte charge. 
20 En l'absence de systemes efficaces de gestion de bases de donnees orientes 

objets, il est tentant d'utiliser les systemes de gestion de bases de donnees 
relationnelles du commerce pour la gestion et le stockage ou la gestion d'objets. 
Toutefois, ces systemes sont mal adaptes a la gestion d'objets. En effet, dans ces 
systemes traditionnels, les donnees sont stockees dans des tables d'ensembles de 
25 donnees ayant une structure fixe, ces ensembles de donnees etant constitues de 
donnees simples. Cela signifie en particulier qu'il n'est pas possible d'imbriquer ou 
d'emboiter des ensembles de donnees a rinterieur d'un autre, meme si les ensembles 
de donnees sont en nombre fixe. 

Ce dernier point pose probleme pour la gestion d'objets en ce que 
30 1'emboTtement d'objets les uns a rinterieur des autres est le fondement meme de la 
gestion de donnees orientee objets. II est theoriquement possible de resoudre ce 
probleme automatiquement en mettant "a plat" la structure de l'objet, c'est-a-dire, en 
considerant que tous les elements de sous-objets inclus dans un objet principal sont 
en fait des elements de l'objet principal. 
3 5 Cela introduit un nouveau probleme en ce que les noms d'elements contenus 

dans des sous-objets distincts d'un meme objet peuvent parfaitement etre identiques 
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et que les noms d'elements dans un meme objet doivent necessairement etre distincts, 
pour d'evidentes raisons de non-ambigui'te. Ce nouveau probleme peut a son tour etre 
resolu automatiquement en incluant le nom du sous-objet contenant dans le nouveau 
nom "a plat" d'un element d'un sous-objet. En pratique, cela revient a ajouter les 
5 noms de tous les objets contenants a l'element contenu pour obtenir un nom "a plat" 
nonambigu. 

Malheureusement, cette technique conduit rapidement a des noms "a plat" 
ayant une longueur de nom depassant les limites autorisees par les systemes de 
gestion de bases de donnees, meme pour des elements peu imbriques, du fait que ces 

10 systemes imposent des limites de Tordre de quelques dizaines de caracteres sur la 
longueur des noms des donnees simples stockees dans une table. Cette nouvelle 
difficulty est habituellement resolue en tronquant le nom "a plat" obtenu a la 
longueur permise par le systeme. Toutefois, ce precede conduit usuellement a des 
noms "a plat" dupliques. 

15 La resolution definitive de ce probleme implique habituellement une 

intervention manuelle d'un operateur humain, qui definit lui-meme les noms a utiliser 
dans le systeme de gestion de base de donnees, pour chaque element d'objet 
imbrique. De facon evidente, cette intervention manuelle est sujette a erreur et elle 
est couteuse en temps humain. 

20 Par ailleurs, la technique consistant a utiliser une table annexe pour chaque 

partie en nombre variable d'un objet conduit rapidement a des performances 
deplorables lorsqu'un objet comporte de nombreuses parties en nombre variable, 
comme c'est souvent le cas en pratique. En effet, chaque acces a un objet stocke dans 
la base de donnees requerra un acces a la base de donnees pour la table principale 

25 plus autant d'acces a la base de donnees qu'il y a de tables annexes, c'est-a-dire, de 
parties d'objets en nombre variable dans un objet. Si 1'objet comporte, comme il est 
frequent, cinq ou dix parties en nombre variable, le nombre d'acces a la base de 
donnees sera multiplie par cinq ou dix par rapport a un objet n'ayant pas de parties 
variables, ce se Uaduit par une degradation des performances dans un meme rapport. 

30 Cette degradation peut devenir critique dans les systemes de stockage de 

donnees tres sollicites, tels que les serveurs Internet, car il n'est pas toujours possible 
de dupliquer les serveurs pour repartir la charge, en particulier lorsque les donnees 
presentes sur un serveur peuvent etre modifiees. En outre, cela augmente dans les 
memes proportions la fragilite du systeme de stockage vis-a-vis d'une panne de 

35 courant ou de tout autre probleme systeme entrainant un arret inopine du systeme 
informatique hebergeant la base de donnees. 
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II existe done un besoin pour un precede qui permette d'adapter les systemes 
de gestion de base de donnees relationnelles existants aux specificites du stockage 
d'objets, en gerant automatiquement les limites imposees sur la longueur des noms 
des donnees simples stockees dans les tables et limitant le nombre de tables annexes 
5 utilisees pour conserver de bonnes performances au systeme de stockage d'objets 
dans son ensemble. 

La presente invention a done pour objet de proposer un procede et un 
systeme qui permettent de limiter a une table principale et une table annexe le 
nombre de tables necessaire pour stocker les donnees simples en nombre fixe et 
1 0 variable d'une collection d'objets informatiques presents dans un systeme de stockage 
de donnees. 

La presente invention propose done un proced6 de stockage d'objets 
informationnels ou objets dans une base de donnees relationnelle stockee dans un 
ordinateur serveur, ladite base de donnees relationnelle etant constituee de tables, 

15 chaque table etant constituee d'un tableau d'ensembles de donnees simples, lesdits 
ensembles ayant la meme structure de donnees dans une meme table, chaque donnee 
simple d'une table etant designee par un identifiant unique dans ladite table, un objet 
etant constitue d'une ou plusieurs donnees simples pouvant etre stockees dans une , 
table de ladite base de donnees, et/ou d'un ou plusieurs objets emboftes dans ledit 

20 objet, ledit emboitement pouvant etre realise sur un nombre quelconque de niveaux 
pour realiser un objet, un objet emboite ou une donnee simple etant dit localement en 
nombre fixe s'il ou elle apparait exactement une fois dans 1'objet le ou la contenant 
immediatement et etant dit localement en nombre variable dans le cas contraire, une 
donnee simple apparaissant a un niveau quelconque dudit objet etant dite 

25 globalement en nombre fixe si elle est localement en nombre fixe et si tous les objets 
la contenant sont localement en nombre fixe, une donnee simple apparaissant a un 
niveau quelconque dudit objet etant dite globalement en nombre variable si elle est 
localement en nombre variable ou si l'un quelconque des objets la contenant est 
localement en nombre variable, lesdites donnees globalement en nombre fixe d'un 

30 objet a stocker etant stockees dans un ensemble de donnees principal stocke dans une 
table principale de ladite base de donnees, lesdites donnees simples globalement en 
nombre variable dudit objet a stocker etant stockees dans une ou plusieurs tables 
annexes de ladite base de donnees, qui a pour caracteristique le fait que, lorsqu'elles 
existent, les donnees simples globalement en nombre variable desdits objets sont 

35 stockees dans une unique table annexe de ladite base de donnees, le procede creant 
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un ou plusieurs ensembles de donnees annexes pour stacker lesdites donnees simples 
globalement en nombre variable dans ladite unique table annexe. 

Dans ce procede, chacun desdits un ou plusieurs ensembles annexes 
eventuellement stockes dans ladite unique table annexe peut comporter en outre un 
5 ensemble d'indicateurs booleens, chaque indicateur booleen etant associe a une 
donnee particuliere desdites donnees simples globalement en nombre variable 
stockees dans ledit ensemble annexe, ledit indicateur booleen indiquant si ladite 
donnee simple globalement en nombre variable associee est definie ou non dans ledit 
ensemble annexe. Dans ce cas, certains desdits indicateurs booleens dudit ensemble 

10 d'indicateurs booleens pourront etre communs a plusieurs donnees simples 
globalement en nombre variable lorsque lesdites donnees simples sont localement en 
nombre fixe dans un meme objet les contenant immediatement. 

De preference, ledit ensemble principal associe au dit objet a stocker 
comportera une donnee permettant d'identifier de fa9on unique ledit ensemble 

15 principal dans ladite table principale. De plus, ladite donnee unique pourra etre 
unique dans ledit ordinateur serveur, et avantageusement, ladite donnee unique 
stockee dans ledit ensemble principal associd au dit objet a stocker sera en outre 
stockee dans chacun des ensembles annexes associes au dit objet a stocker, pour 
permettre la mise en relation dudit ensemble principal et du ou desdits ensembles 

20 annexes eventuels associes au dit objet a stocker. 

De facon avantageuse, ladite donnee unique pourra etre constitute du nom 
logique de l'ordinateur serveur sur ledit reseau, du numero de table de ladite table 
principale dans ladite base de donnees et du numero d'ensemble de donnees dudit 
ensemble principal dans ladite table principale, ledit nom logique de l'ordinateur 

25 serveur etant unique sur ledit reseau, ladite base de donnees etant unique sur ledit 
ordinateur serveur, ledit numero de table de ladite table principale etant unique dans 
ladite base de donnees et ledit numero d'ensemble de donnees dudit ensemble 
principal etant unique dans ladite table principale. 

Dans le procede, deux objets a stocker pourront etre dits de meme type s'ils 

30 sont constitues de donnees simples et d'objets emboites de m&tne type, deux objets de 
meme type ayant en commun un meme identifiant et les donnees simples et/ou les 
objets emboites se correspondant a un niveau quelconque desdits objets de meme 
type ayant en commun un meme identifiant, unique dans I'objet les contenant 
immediatement. 

35 Dans ce cas, le procede pourra creer un identifiant global pour tous les 

objets de meme type et pour toutes les donnees simples se correspondant a un niveau 
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quelconque desdits objets de meme type, ledit identifiant global etant ledit identifiant 
commun pour lesdits objets de meme type, et ledit identifiant global etant obtenu, 
pour chacune desdites donnees simples se correspondant, par la concatenation des 
identifiants, dans les objets les contenant irnmediatement, de tous les objets 
5 contenant ladite donnee simple, et de l'identifiant de ladite donnee simple dans l'objet 
la contenant immediatement. 

En outre, le nombre de caracteres de eet identifiant global pourra etre 
tronque au nombre de caracteres permis par ladite base de donnees pour l'identifiant 
d'une donnee stockee dans une table de ladite base de donnees. Egalement, une 
10 ambiguite pouvant apparaitre du fait de ladite troncature pourra etre resolue en 
effectuant les etapes consistant a : 

- remplacer le dernier caractere alphabetique de l'identifiant global par le 
chiffre zero, ainsi que les eventuels chiffres le suivant ; 

augnienter d'une unite le nombre constitue par l'ensemble des chiffres 
15 apparaissant a la fin dudit identifiant global jusqu'a ce que l'ambiguite 

disparaisse ou que les chiffres a la fin dudit identifiant global soient 
entierement constitues de chiffres neuf ; 

- repeter les etapes precedentes depuis le debut lorsque les chiffres 
apparaissant a la fin dudit identifiant global sont entierement constitues 

20 de chiffres neuf a Tissue de l'etape precedente. 

Dans le procede de l'invention, les objets stockes dans la base de donnees 
pourront etre re9us ou transmis par rordinateur serveur via un reseau informatique de 
type Internet. 

De preference, les donnees simples constituant lesdits objets (6) stockes 
25 dans ladite base de donnees seront de type texte, et avantageusement, lesdites 
donnees simples de type texte seront des donnees ecrites en langage XML. De plus, 
. lesdites donnees ecrites en langage XML pourront etre conformes a une description 
de type XML Schema. 

En outre, un ensemble de donnees au format XML pourra etre obtenu par 
30 une traduction automatique de ladite description, ledit ensemble de donnees et un 
ensemble de donnees complementaire etant a leur tour traduits automatiquement en 
langage SQL pour definir et gerer la structure de la base de donnees, et pour controler 
les echanges de donnees avec ladite base de doimees. 

Par ailleurs, dans le precede de l'invention, une partie des donnees simples 
35 des objets recus par ledit reseau de type Internet pourra etre supprimee a l'aide d'un 
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patron, ou modele, d'objet ecrit en langage XML, povir interdire la modification 
desdites donnees simples via ledit reseau. 

Egalement, une partie des donnees simples des objets transmis via ledit 
reseau pourra etre supprimee a l'aide d'un patron d'objet ecrit en langage XML pour 
5 limiter la transmission sur ledit reseau a certaines donnees simples desdits objets. De 
plus, la suppression d'une partie des donnees simples contenues dans les objets 
permettra en outre d'optimiser les requetes a ladite base de donnees. 

L'invention propose en outre un systeme de stockage d'objets 
informationnels ou objets, dans une base de donnees relationnelle stockee par un 
10 ordinateur serveur, qui a pour caracteristique le fait qu'il met en oeuvre le precede 
selon Tune quelconques des revendications precedentes. 

Un mode de realisation preferentiel de l'invention va maintenant etre decrit, 
a titre d'exemple seulement, en se referant aux dessins annexes, dans lesquels : 

- la figure l~est le schema fonctionnel du mode de realisation prefere du 
1 5 precede de stockage d'objets selon la presente invention ; 

- la figure 2 est un schema montant l'utilisation d'une table annexe unique 
pour les ensembles en nombre variable dans le mode de realisation 
prefere du precede de rinvention sur un cas d'exemple ; 

- la figure 3 est un schema montant l'utilisation d'un ensemble de tables 
20 annexes pour les ensembles en nombre variables dans la technique 

anterieure, sur le meme cas d'exemple que celui de la figure 2. 
Pour permettre la comparaison, un exemple de stockage d'objet de la 
technique anterieure sera egalement decrit. Dans les deux cas, on supposera, de facon 
non restrictive, que le systeme de gestion de base de donnees relationnelle, ou 
25 SGBDR, utilise est mis en oeuvre a l'aide du langage standard Structured Query 
Language, ou SQL. 

Par ailleurs, pour faciliter la comprehension, on decrira les operations de 
stockage concernant un objet 6 d'exemple, tel qu'une entree dans un annuaire 
comportant les informations suivantes : 
30 Entree annuaire : 

Norn, sur 40 caracteres : OTOOBE 
Telephone, sur 15 caracteres : +33(0)1 44 34 85 03 
Telecopie, sur 15 caracteres : +33(0)1 44 34 85 01 
Adresse : 

35 Rue, sur 40 caracteres : 3 bis, rue du Docteur-Foucault 

Ville, sur 40 caracteres : 92000 NANTERRE 
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Adresse : 

Rue, sur 40 caracteres : 34, bd Haussmann 
Ville, sur 40 caracteres : 75009 PARIS 
Contact, sur 40 caracteres : M. Laurent QUEREL 
5 Contact, sur 40 caracteres : M. Jean-Francois QUENTIN 

Contact, sur 40 caracteres : M. Gilles ANDRE 

Dans cette entree, les donnees "Adresse" et "Contact" sont supposees 
pouvoir figurer en nombre variable dans ledit objet 6 "Entree annuaire", pour prendre 
en compte le fait qu'une entreprise peut comporter plusieurs etablissement et 

10 plusieurs personnes a contacter. Pour la clarte de l'expose, le nombre des donnees en 
nombre variable a ete limite a deux dans cet exemple, mais ce nombre ne limite en 
rien la portee du procede de la presente invention. 

Les objets informationnels, ou objets, dont la structure de donnees n'est pas 
fixe, permettent de prendre en compte ce type de donnees en nombre variable, , ce qui 

1 5 fait toute la puissance de l'approche objet par rapport a une approche traditionnelle ou 
la structure des donnees est fixe, et dans laquelle il est done neeessaire de prevoir a . 
l'avance un nombre maximal d'occurrences pour chaque donn6e, au risque d'un cote" 
de bloquer de facon genante un cas particulier ou un nombre d'occurrences plus , 
important que celui prevu serait neeessaire, et d'un autre cote, de gaspiller 

20 inutilement de la place de stockage dans le cas general pour quelques cas particuliers 
peu frequents. 

Malheureusement, les systemes de gestion de base de donnees classiques 
actuels ne permettent pas directement le stockage d'objets, e'est-a-dire de structures 
de donnees permettant l'emboitement de sous-structures de donnees et des 
25 occurrences multiples pour les elements de ces structures, ce qui necessite un 
traitement particulier des donnees de l'objet 6 "Entree annuaire" pour pouvoir le 
stocker dans la base de donnees 2. 

Dans la technique anterieure, ce traitement consiste a separer les donnees en 
nombre fixe "nom", "telephone", "telecopie" et les donnees en nombre variable "rue", 
30 "ville" en stockant les donnees en nombre fixe dans une premiere table principale 3, 
et en stockant les donnees, ou ensembles de donnees, en nombre variable dans autant 
d'autres tables annexes qu'il existe de donnees, ou d'ensembles de donnees, en 
nombre variable dans l'objet 6. 

Dans la technique anterieure, l'objet 6 de l'exemple precedent est alors 
3 5 stocke sous la forme indique a la figure 3, dans laquelle : 
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- la table 3 est la table-principale stockant les ensembles 3 1 de donnees en 
nombre fixe constitues des donnees simples "cle" 11, "nom" 12, 
"telephone" 1 3 et "telecopie" 14; 

- la table 4 est une premiere table annexe stockant les ensembles 41 
5 constitues de la donnee simple "cle" 11 et de la donnee en nombre 

variable "adresse", c'est-a-dire, des donnees simples "rue" 15 et "ville" 
16; 

- la table 5 est une seconde table annexe stockant les ensembles de 
donnees constitues de la donnee "cle" 11 et de la donnee en nombre 

10 variable "contact" 17. 

Plus precisement, dans l'exemple ci-dessus, la donnee "nom" ayant pour 
valeur "OTOOBE" sera stockee en 12, la donnee "telephone" ayant pour valeur 
"+33(0)1 44 34 85 03" sera stockee en 13, la donnee "telecopie" ayant pour valeur 
"+33(0)1 44 34 85 01" sera stockee en 14, la donnee "rue" du premier sous-objet 

1 5 "adresse", ayant pour valeur "3bis, rue du Docteur-Foucault", sera stockee en 15i, la 
donnee "ville" du premier sous-objet "adresse", ayant pour valeur "92000 
NANTERRE", sera stockee en \6 X , la donnee "rue" du second sous-objet "adresse", 
ayant pour valeur "34, bd Haussmann", sera stockee en 15 2 , la donnee "ville" du 
second sous-objet "adresse", ayant pour valeur "75009 PARIS", sera stock6e en 16 2 , 

20 la premiere donnee "contact", ayant pour valeur "M. Laurent QUEREL", sera stockee 
en 17i, la seconde donnee "contact", ayant pour valeur "M. Jean-Francis 
QUENTE^", sera stockee en \1 2 et la troisieme donnee "contact", ayant pour valeur 
"M. Gilles ANDRE", sera stockee en 17 3 . 

La donnee "cle" 11 apparaissant dans les tfois tables 3, 4 et 5 est la cle 

25 primaire de ces tables, et son utilisation sera decrite plus loin. 

Pour pouvoir utiliser ces donnees, il faut au prealable definir les tables 3, 4 
et 5 dans la base de donnees 2, ainsi que les diverses donnees stockees dans ces 
tables 3, 4 et 5. 

Dans la technique anterieure, pour creer la table 3, un operateur devait 
3 0 typiquement indiquer manuellement au SGBDR une instruction SQL du type : 
CREATE TABLE "EntreeAnnuaire main" ( 
cle INTEGER, 
nom VARCHAR(40), 
telephone VARCHAR(15), 
35 telecopie VARCHAR(15), 

PRIMARY KEY (cle)) 



WO 02/03245 



PCT/FROO/01902 



9 

Dans cette instruction, la rubrique "EntreeAnnuaire_main" indique le nom, 
librement choisi par l'operateur sous reserve d'unicite, de la table principale 3, et une 
rubrique "VARCHAR(n) M indique une chaine de caracteres de longueur variable et 
de longueur maximale n. La donnee "cle" 1 1 est la cle primaire evoquee ci-dessus et 
5 qui sera decrite plus loin, et la rubrique "PRIMARY KEY(cle)" indique precisement 
au systeme que cette donnee "cle" 1 1 est la cle primaire. 

De meme, dans la technique anterieure, pour creer les tables 4 et 5, un 
operateur devait typiquement indiquer manuellement au SGBDR des instructions 
SQL du type : 

10 CREATE TABLE "EntreeAnnuaire_l " ( 

cle INTEGER, 
rue VARCHAR(40), 
villeVARCHAR(15), 
PRIMARY KEY (cle)) 

15 el : 

CREATE TABLE "EntreeAnnuaire_2" ( 
cle INTEGER, 
contact VARCHAR(40), 
PRIMARY KEY (cle)) 

20 dans lesquelles les rubriques "EntreeAnnuaire_l" et "EntreeAnnuaire_2" sont les 
noms respectifs, librement choisis, des tables annexes 4 et 5. 

En outre, l'operateur devait definir egalement manuellement les donnees 
indexees, e'est-a-dire les donnees dont le contenu pourra permettre de retrouver une 
entree de l'annuaire, au moyen d'instructions SQL du type : 
25 CREATE INDEX "IndexNom" ON "EntreeAnnuaire_main" (nom) 

qui indique au SGBDR de faire en sorte qu'une entree d'annuaire puisse etre 
retrouvee par le contenu de la rubrique "nom" de la table principale 3 
"Entree Annuaire_main" . 

De plus, dans le cas d'objets 6 comportant de nombreux niveaux 
30 d'emboitement et de nombreuses donnees en nombre variable comme e'est souvent le 
cas en pratique, le nombre de tables annexes etait eleve, et la numerotation ou la 
denomination des tables annexes etait beaucoup plus complexe que celle presentee 
dans l'exemple precedent. A nouveau, cette numerotation ou cette denomination 
necessitait une intervention manueUe d*un operateur, avec les risques d'erreur 
3 5 inherents a toute operation manueUe. 
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En se referent aux figures 1 et 2, on va maintenant decrire le precede de 
stockage selon le mode de realisation prefere de l'invention, qui est mis en oeuvre par 
divers modules de programmes globalement denommes Collective Operating System 
ou COS dans ce document. 
5 En revenant a l'exemple precedent, le precede de rinvention gere l'ensemble 

31 de donnees simples en nombre fixe "cle" 11, "nom" 12, "telephone" 13, et 
"telecopie" 14 dans la table principale 3 de la meme maniere que dans la technique 
anterieure, c'est-a-dire en utilisant directement les primitives adequates du SGBDR 
utilise. 

10 Par contre, la gestion des donnees simple en nombre variable est effectuee a 

l'aide d'une unique table 7, au lieu des tables 4 et 5. Pour cela, le precede de 
l'invention stocke la premiere occurrence d'une donnee simple en nombre variable 
dans un premier ensemble de donnees 71, de la table 1, la seconde occurrence d'une 
donnee simple en nombre variable dans un second ensemble de donnees 71 2 de la 

15 table 7, la troisieme occurrence eventuelle d'une donnee simple en nombre variable 
dans un troisieme ensemble de donnees 71 3 , etc.. On voit alors que la structure de 
donnees de la table 7, c'est-a-dire la structure des ensembles de donnees 71, doit 
necessairement comporter au moins l'union des donnees simples en nombre variable 
dans un objet 6. 

20 Comme dans la technique anterieure, la donnee "cle" 1 1 apparaissant dans 

les deux tables 3 et 7 est la cle primaire de ces tables, et son utilisation sera decrite 
plus loin. 

En revenant a l'exemple precedent, le precede stocke done la donnee 
premiere occurrence de la donnee simple "rue" de l'objet 6 dans l'emplacement 15, de 

25 l'ensemble 71] de la table 7, il stocke la premiere occurrence de la donnee "ville" 
dans l'emplacement 16, de l'ensemble 71 j de la table 7, il stocke la seconde 
occurrence de la donnee "rue" dans l'emplacement 15 2 de l'ensemble 71 2 , il stocke la 
seconde occurrence de la donnee "ville" 16 2 dans l'emplacement 16 2 de l'ensemble 
71 2 , il stocke la premiere occurrence de la donnee "contact" 17! dans l'emplacement 

30 17i de l'ensemble 71 1, il stocke la seconde occurrence de la donnee "contact" 17 2 
dans l'emplacement 17 2 de l'ensemble 71 2 , et il stocke la troisieme occurrence de la 
donnee "contact" 17 3 dans l'emplacement 17 3 de l'ensemble 71 3 . 

Toutefois, on voit dans ce qui precede que les emplacements correspondants 
aux donnees simples "rue" et "ville" aux emplacements 15 3 et 16 3 dans l'ensemble de 

35 donnees simples 71 3 ne sont pas remplis, ce qui est du au fait qu'il n'y a que deux 
ensembles de donnees en nombre variable "rue" et "ville", et qu'il y a trois donnees 
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en nombre variable "contact". Cela pose un probleme en ce sens que si les ensembles 
de donnees simples 71 1, 71 2 , 71 3 etaient stockes en l'etat dans la base de donnees, 
rinformation concernant quels emplacements sont remplis et quels emplacements 
sont vides serait longue et difficile a determiner. II serait en effet necessaire de tester 
5 la nullite des colonnes de l'ensemble de ces donnees simples nombre variable pour 
determiner l'absence ou la presence de ces donnees en nombre variable. 

Pour resoudre ce probleme, le procede selon rinvention reservera en outre, 
dans chaque ensemble 71, des emplacements de donnees pour stocker cette 
information de presence ou d'absence pour chaque donnee en nombre variable dans 
10 cet ensemble 71. 

En pratique, dans le cas de donnees simples en nombre fixe, telles que "rue" 
et "ville" associees dans un meme sous-objet contenant tel que "adresse", les donnees 
simples en nombre fixe associees seront toujours presentes ou absentes 
simultanement, ce qui signifie que le procede pourra optimiser le nombre 
15 d'indicateurs en ne stockant qu'un seul indicateur par ensemble de donnees en 
nombre fixe associees. 

Dans ces conditions, lors de la creation de la table 7, le proc6d6 ajoute dans 
la structure de donnees de la table 7, c'est-a-dire dans chaque ensemble 71, une 
donnee booleenne pour chaque ensemble de donnees en nombre variable dans l'objet 
20 6. Dans l'exemple decrit, l'ensemble de donnees simples 72 constitue des donnees 
simples booleennes 20 et 21 est ainsi ajoute a chaque ensemble 71, la donnee 
booleenne 20 indiquant la presence, dans l'ensemble 71 considere, de l'ensemble 
constitue des donnees simples "rue" 15 et "ville" 16, et la donnee booleenne 21 
indiquant la presence, dans l'ensemble 71 considere de la donnee "contact" 17. 
25 Ainsi, les informations de presence ou d'absence des donnees ou des 

ensembles de donnees en nombre variable seront conservees lors de l'ecriture d'un 
objet 6, et le procede pourra utiliser ces informations lors des relectures ulterieures, 
pour reconstituer correctement l'objet 6 tel qu'il etait au moment de son 
enregistrement. 

30 On notera qu'avec le procede de l'invention, le nombre d'ensembles de 

donnee presents dans l'unique table annexe est egal au maximum des nombres des 
donnees en nombre variable dans l'objet 6, alors que ce nombre d'ensembles de 
donnees dans les tables annexes est egal a la somme des nombres de donnees en 
nombre variable de l'objet 6 dans la technique anterieure, c'est-a-dire un nombre 

35 toujours plus eleve. 
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Par ailleurs, dans le mode de realisation preferentiel, le procede est utilise 
pour stocker des objets 6 ecrits en langage XML qui sont conformes a une 
description 92 de type XML Schema, ce qui signifie en particulier que cette 
description est elle-meme ecrite dans le langage XML. 

Cette description 92, denommee COSSchema dans le mode de realisation 
preferentiel, decrit la structure de donnees des objets 6. L'interet de cette description 
XML Schema 92 est de constituer une definition de reference unique pour la 
structure des objets 6, modele qui sera utilise chaque fois qu'il sera necessaire de 
verifier la structure ou la validite des objets 6. 

Dans le mode de realisation preferentiel, un certain nombre de definitions 
Jnhjcts utilisees dans le schema COSSchema 92 sont derivees a partir de definitions 
siiK-kccs dans un autre schema XML Schema 91, denomme COSCoreSchema. 

L'interet de cette approche est de permettre au COS d'uniformiser les 
definitions de certains objets en leur dormant une base commune, et de pouvoir 
event in;! lement effectuer un certain nombre de travaux, en particulier de 
maintenance, dc fa9on homogene sur ces objets. Par exemple, s'il s'avere necessaire 
d'introduire une nouvelle donnee simple ou de modifier une donnee simple existante 
dans un type de base defini dans le COSCoreSchema, il ne sera pas necessaire de. 
reproduirc la nouvelle donnee simple ou la modification dans tous les objets bases 
sur ce type, et la modification sera implicitement reproduite via la seule reference au 
type de base. Ainsi, les risques d'erreur au niveau de la structure des objets COS 
seront reduits d'autant, et la maintenance de ces objets s'en trouvera facilitee. 

En revenant a l'exemple d'entree d'annuaire vue precedemment, dans le 
mode de realisation prefere de l'invention, celle-ci sera constituee d'un objet 6, se 
presentant en langage XML sous la forme suivante : 
<entree_annuaire> 

<nom>OTOOBE<ynom> 

<telephone>+33(0)l 44 34 85 03</telephone> 

<telecopie>+33(0)l 44 34 85 01</telecopie> 

<adresse> 

<rue>3bis, me du Docteur-Foucault</rue> 
<ville>92000NANTERRE</ville> ; 
</adresse> 

<adresse> i 
<rue>34, bd Haussmann</rue> 
<ville>75009 PARIS</ville> 
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</adresse> 

<contact>M. Laurent QUEREL</contact> 
<contact>M. Jean-Fran9ois QUENTIN</contact> 
<contact>M. Gilles ANDRE</contact> 
5 </entree_annuaire> 

Cet objet sera typiquement conforme a un fragment du COSSchema, qui est 
de type XML Schema, se presentant sous la forme suivante : 
<type name="entree_annuaire"> 

<element name="nom" minOccurs- T'> 
1 0 <datatype source="string"> 

<length value="40*'/> 
</datatype> 
</element> 

<element name="telephone" minOccurs- ' 1 "> 
\ 5 <datatype source=" string"> 

<length value=" 1 5"/> 
</datatype> 
</element> 

<element name="telecopie" minOccurs="l"> 
20 <datatype source="string"> 

<length value- '157> 
</datatype> 
</element> 

<type name- 'adresse" rninOccurs=" 1 " maxOccurs=" * "> 
25 <element name="rue" minOccurs=" 1 "> 

<datatype souice="string"> 
<length value="40"/> 
</datatype> 
</element> 

3 0 <element name="ville" minOccurs-' 1 "> 

<datatype source="string"> 
<length value="40"^> 
</datatype> 
</element> 
35 </type> 

<element name=" contact" minOccurs="0" maxOccurs="*"> 
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<datatype source- 'string'^ 
<length value="40"/> 
</datatype> 
</element> 
5 </type> 

Dans cette definition XML Schema, le parametre 'minOccurs' d'une donnee 
simple ou d'un sous-objet emboite indique le nombre rninimum de fois ou la donnee 
concernee apparait dans l'objet immediatement contenant, et le parametre 
'maxOccurs' d'une donnee simple ou d'un sous-objet emboite indique le nombre 
1 0 maximum de fois ou la donnee concernee apparait dans l'objet immediatement 
contenant. Par defaut, c'est-a-dire lorsque 'maxOccurs' n'apparait pas, il est suppose 
etreegalal. 

La signification de 'maxOccurs="*"* est que la donnee ou le sous-objet 
concerne peut apparaitre un nombre quelconque de fois dans l'objet immediatement 
15 contenant. 

Dans le mode de realisation prefere de l'invention, le precede utilise cette 
description au format XML, en association avec le procede^ de stockage d'objets dans 
seulement deux tables qui a ete demerit plus haut, pour generer automatiquement des 
instructions SQL pour creer et gerer les donnees de la base de donnees 2 reprSsentant 

20 les objets stockes. 

Pour cela, le procede de l'invention part du COSSchema et il applique un 
certain nombre de regies pour obtenir un format XML Schema etendu, denomm6 
XDB Schema, comparable a celui de l'exemple decrit ci-dessus. En effet, dans le 
COSSchema, la description des donnees est faite, de fa9on structuree, en se referant a 

25 d'autres types predefinis, tels que les types dermis dans le COSCoreSchema ou a des 
types intermediaires definis dans le COSSchema lui-meme. Pour rendre utilisables 
dans le langage SQL utilise les informations presentes dans le COS Schema, le 
procede de l'invention, applique done a ce schema COS Schema un certain nombre 
de regies de traduction lui permettant de passer d'une representation comportant des 

30 types non simples a une representation ne comportant plus que des types simples. Le 
resultat de cette traduction constitue le schema XDB Schema. 

Toutefois, le schema XDB Schema obtenu precedemment n'est pas suftisant 
a lui seul pour definir completement la structure de l'objet 6 dans la base de donnees 
2 : en effet, il manque les informations permettant de definir les donnees de l'objet 6 

35 qui seront indexees. Pour resoudre ce probleme, le procede de l'invention utilise un 
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schema XML 96 complementaire, denomme XDB Mapping, decrivant les donnees a 
indexer dans les tables stockant les donnees de l'objet 6. 

Ce schema XDB Mapping 96 reprend la structure du schema COSSchema 
en la limitant aux donnees devant faire l'objet d'une indexation. Ainsi, dans l'exemple 
5 precedent ou la donnee "nom" devait etre indexee, le fragment correspondant dans le 
XDB Mapping sera du type suivant : 
<type name="entree_annuaire"> 

<element name="nom" sql:indexname="IndexNom" sql:indexType="..."/> 
</type> 

10 ou la rubrique "sqhindexname" indique le nom de l'index a creer, ici "IndexNom", et 
ou la rubrique "sqlrindexType" sert a indiquer, sous une syntaxe adequate, des 
parametres pour l'index a creer, tels que "ordre de tri croissant", "pas de distinction 
minuscules/majuscules", etc.. Ainsi, avec ce schema XDB Schema, le procede de 
l'invention possede toutes les informations utiles pour creer automatiquement dans la 
1 5 base de donnees 2 toutes les donnees necessaires pour l'objet 6 a creer. 

Ensuite, le procede traduit ces schemas XDB Schema et XDB Mapping en 
instructions SQL a destination du SGBD gerant la base de donnees 2. 

Toutefois, avant de pouvoir mener a bien cette operation, un autre probleme, 
lie aux possibility offertes par les objets, doit etre resolu. En effet, 1'approche 
20 orientee objet permet a des donnees simples, ou a des sous-objets, contenus dans des 
sous-objets distincts d'avoir le meme identifiant, pourvu que cet identifiant soit 
unique dans le sous-objet, ou l'objet 6, les contenant immediatement. Cette 
possibility de noms dupliques dans des sous-objets differents interdit d'utiliser 
directement ces identifiants comme identifiants globaux de donnees dans la base de 
25 donnees 2, car deux donnees distinctes d'une meme table pourraient alors recevoir le 
meme identifiant, ce qui est interdit par tous les SGBDR existants. 

Pour resoudre ce probleme, le procede cree pour chaque donnee simple un 
identifiant global obtenu en prefixant l'identifiant de la donnee simple, tel qu'il 
apparait dans la rubrique 'name="...'" de la definition de la donnee simple dans le 
30 schema XDB Schema, par la concatenation des identifiants, tels qu'il apparaissent 
dans les rubriques 'name="..."' des definitions correspondantes du schema XDB 
Schema, de tous les sous-objets contenant, a une niveau ou un autre, la donnee 
simple consideree. Ce procede leve Tambiguite qui pourrait apparaitre, car du fait que 
les identifiants des donnees simples ou des sous-objets dans leurs objets 
35 immediatement contenant sont distincts, deux identifiants globaux obtenus de cette 
faoon sont necessairement distincts globalement. 
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Ainsi, dans l'exemple ci-dessus, 1'identifiant global de la donnee "nom" sera 
"nom" lui-meme, puisque la donnee simple "nom" n'est pas contenue dans un sous- 
objet ; par contre, 1'identifiant global de la donnee "rue" contenue dans le sous-objet 
"adresse" sera "adresse_rue". 
5 Dans ce qui precede, on a indique que les identifiants des donnees creees 

dans les tables 3 et 7 de la base de donnees 2 etait la concatenation des identifiants de 
la donnee et de tous les sous-objets la contenant dans l'objet 6. Toutefois, cela pose 
probleme en ce que la longueur de ces identifiants est habituellement limitee par les 
SGBDR classiques a une valeur assez basse, de l'ordre de quelques dizaines de 

10 caracteres, et que, pour des objets comportant un niveau d'emboitement meme 
modere, cette limite est tres vite atteinte. 

Pour resoudre ce probleme, le procede de l'invention tronque les identifiants 
precedemment obtenus a la longueur permise par le SGBDR pour les identifiants de 
donnees d'une table. A Tissue de cette troncature, si 1'identifiant global obtenu est 

15 deja present dans la table ou il devait etre cree, le procede de l'invention realise les 
etapes suivantes : 

1°/ le dernier caractere alphabetique de 1'identifiant global precedemment 
obtenu est remplac6 par le chififre "0", ainsi que tous les chiffres le suivant 
eventuellement ; 

20 2° I si 1'identifiant global ainsi obtenu est encore present dans la table, le 

nombre constitue par I'ensemble des chiffies apparaissant a la fin de 1'identifiant 
global est augmente d'une unite et l'etape 2 est repetee tant qu'un nombre entierement 
constitue de chiffies "9" n'a pas ete atteint ; 

3°/ si un nombre entierement constitue de chiffies "9" est atteint a l'etape 2, 
25 alors le procede retourne a l'etape 1 . 

Les etapes 1°/ a 3°/ precedentes sont repetees jusqu'a ce qu'un identifiant 
global, nouveau dans la table consideree, soit trouve. 

Ainsi, le procede ci-dessus decrit permet de lever les ambigultes, dans les 
identifiants globaux attribues aux donnees simples stockees dans la base de donnees 
30 2, qui peuvent apparaitre du fait de la possibility de duplication d'un identifiant de 
donnee ou de sous-objet dans des sous-objets distincts. 

En utilisant ce procede de generation d'identifiants globaux pour les donnees 
simples d'un objet 6, le proc6d<£ relit alors en parallele le schema XDB Schema et 
XDB Mapping, et pour chaque nouveau type d'objet a creer 6 trouve dans le schema 
35 XDB Schema, il applique le procede suivant : 
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- le procede cree alors dans la base de donnees une table principale 3 
portant le nom de l'objet 6, suivi du suffixe "jmain", comportant une 
donnee "cle" 11 servant a identifier de facon unique dans la base de 
donnees un objet 6 ; ainsi, lorsqu'il rencontre dans le schema XDB 

5 Schema la definition : 

<type name="entree_annuaire"> 

</type> 

le procede cree la table principale 3 "EntreeAnnuairemain" 
1 0 correspondante par l'instruction SQL : 

CREATE TABLE "Entree Annuaire main" (cle INTEGER, 
PRIMARY KEY (cle)) 

- ensuite, le procede explore les definitions "<element ...>...</element>" du 
schema XDB Schema, XDB Schema et pour chaque donnee simple 

1 5 rencontree, telles que "nom" ou "contact", il determine si cette donnee est 

en nombre fixe ou variable ; une donnee simple sera dite en nombre fixe 
si sa rubrique "maxOccurs" est absente de la definition et si cette donnee 
simple n'est pas contenue a un niveau quelconque dans un sous-objet en 
nombre variable, c'est-a-dire un sous-objet dont la rubrique "maxOccurs" 

20 serait presente et differente de la rubrique "minOccurs" dudit sous-objet ; 

une donnee sera dite en nombre variable dans le cas contraire, c'est-a-dire 
si elle n'est pas en nombre simple au regard de la definition precedente ; 

- lorsque le procede rencontre une donnee en nombre fixe telle que la 
donnee "nom" dans l'exemple ci-dessus, il ajoute cette donnee en nombre 

25 fixe dans la table principale 3 a 1'aide d'une instruction SQL telle que : 

ALTER TABLE "EntreeAnnuaire_main" ADD nom VARCHAR(40) 
dans laquelle l'identifiant global "nom" est obtenu par le procede decrit 
plus haut, et dans laquelle la longueur "40" apparaissant dans la rubrique 
"VARCHAR" est reprise de la '<length value="...">' de la definition 

30 correspondante ; en outre, si le procede trouve dans le schema XDB 

Mapping une definition d'index portant sur la donnee qu'il vient de creer 
dans la table principale, le procede cree un index pour cette donnee a 
l'aide d'une instruction SQL adequate telle que : 
CREATE INDEX "IndexNom" ON "EntreeAnnuaire_main" (nom) 
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dans laquelle le nom de l'index "IndexNom" est celui retrouve dans la 
rubrique "sql:indexname" de la definition correspondante du schema 
XDB Mapping ; 

lorsque le procede rencontre une donnee en nombre variable telle que la 
donnee "contact" dans l'exemple ci-dessus, il effectue les operations 



■ s'il n'existe pas deja une table annexe 7 associee a cette table 
principale 3, il cree cette table annexe a l'aide d'une instruction SQL 
telle que : 

10 CREATE TABLE "EntreeAnnuaire_annex" (cle INTEGER, 

PRIMARY KEY (cle)) 

■ dans laquelle la donnee "cle" est la donnee servant a identifier de 
facon unique un objet 6 dans la base de donnees 2 ; 

■ ensuite, le procede cree la donnee correspondante dans la seconde 
15 table, en lui associant, de la fa9on decrite precedemment, une 

donnee booleenne "presence", permettant de savoir si la donnee 
correspondante est presente ou non dans l'ensemble de donnees 71 
consideie; par exemple, pour la donnee en nombre variable 
"contact" 17, cette creation sera realisee a l'aide d'une instruction 
20 SQL telle que: 

ALTER TABLE "EntreeAnnuaire_annex" ADD contact 
VARCHAR(40), ADD presence_contact BOOLEAN 

■ dans laquelle l'identifiant global est obtenu par le procede decrit 
plus haut, et dans laquelle longueur "40" apparaissant dans la 

25 rubrique "VARCHAR" est reprise de la rubrique '<length 

value="...">* de la definition correspondante dans le schema XDB 
Schema ; 

■ dans le cas d'une donnee incluse dans un sous-objet comme la 
donnee "rue", l'identifiant global sera obtenu comme indique 

30 precedemment, et I'instruction SQL correspondante sera, par 

exemple : 

ALTER TABLE ''EntreeAnnuaire annex" ADD adresse_rue 

VARCHAR(40), ADD presence_adresse_rue BOOLEAN. 
Le procede repete les operations precedentes jusqu'a ce que toutes les 
35 definitions presentes dans le schema XDB Schema 61 aient ete traitees. A Tissue de 
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ce traitement, le precede aura done cree automatiquement la structure d'objets 6 dans 
la base de donnees 2, telle qu'elle etait decrite dans le schema COS Schema. 

Dans le mode de realisation de la presente invention, les aspects ci-dessus 
du precede de l'invention sont implemented dans un programme 90 denomme XBD 
5 Engine, et, contrairement a la technique anterieure, le precede de l'invention permet 
de realiser la creation de nouveau type d'objet 6 dans la base de donnees 2 sans 
intervention manuelle d'un operateur, ce qui se traduit par un gain de temps tres 
appreciable et une diminution considerable du risque d'erreur, tant pour la creation 
que pour la modification, dans la base de donnees, de la structure d'un objet 6. 

10 Dans ce qui precede, on a decrit le precede de l'invention comme 

transformant le schema COS Schema, comportant des types predefinis, en un schema 
XML, le schema XDB Schema, ne comportant plus que des types de donnees simples 
tels qu'utilises par le SGBDR. Cela a ete fait dans l'optique de l'utilisation d'un 
langage SQL de base, qui ne connait pas de types autres que ces types simples. 

15 Toutefois, dans le cas de l'utilisation d'un langage SQL evolue, tel que le 

langage SQL 3, le precede de l'invention tirera naturellement parti des possibilites de 
typage offertes par ce langage en ne traduisant en types plus simples que les types ne 
pouvant pas Stre "compris" directement par le langage SQL utilised Les types utilises 
par le COS Schema et pouvant etre traduits directement en types SQL, le seront a 

20 l'aide d'une instruction SQL adequate, telle que : 
CREATE TYPE ... 

Dans ce qui precede, on a decrit sur un exemple les etapes de creation d'un 
nouveau type d'objet 6 a stocker dans la base de donnees 2, tant dans la technique 
anterieure que dans le precede de l'invention. Les informations contenues dans 
25 COSSchema et XDBSchema seront bien evidemment reutilisees pour modifier la 
structure d'un objet 6 deja existant dans la base de donnees 2, apres que les 
modifications voulues y aient ete apportees. Cette modification de la structure d'un 
type d'objet 6 deja existant est en tout point similaire a la creation precedemment 
decrite. Ainsi, par exemple, pour modifier une table 3; existante et y ajouter un 
30 nouveau champ, l'instruction SQL utilisee, tant dans la technique anterieure que dans 
le precede de l'invention : 

CREATE TABLE... 
sera remplacee, par exemple, par l'instruction SQL : 

ALTER TABLE "EntreeAnnuaire_main" ADD telex VARCHAR(15), 
35 DROP telecopie 
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qui indique qu'une donnee "telex" sur quinze caracteres doit, etre ajoutee et que la 
donnee "telecopie" doit etre supprimee. 

De meme, la suppression de l'index sur la donnee "nom" dans la table 3 se 
ferait, tant dans la technique anterieure que dans le precede de l'invention, par 
5 l'instruction SQL : 

DROP INDEX EntreeAnnuaireindexNom 

Dans le cas du procede de l'invention, a nouveau ces modifications sont 
effectuees de facon automatique par le programme XDB Engine. 

Compte-tenu de ces similitudes, la modification de la structure d'un objet 6 
1 0 stocke dans la base de donnees 2 par le procede de l'invention ne sera pas decrite plus 
en detail. 

Dans ce qui suit, on va maintenant decrire le fonctionnement du procede 
selon la presente invention en comparaison avec la technique anterieure pour le 
stockage et la gestion des donnees en nombre variable d'un objet 6. 
.15 En se referant aux figures 2 et 3, un systeme de stockage des donnees 

simples d'un objet 6, dans la technique anterieure comme dans le procede de 
l'invention, est constitue d'un ordinateur 1 hebergeant une base de donnees 
relationnelle 2. Les ensembles de donnees simples d'une table principale telle que la 
table principale 3, ou ceux d'une table annexe telles que les tables 4, 5 ou 7, sont 
20 geres a l'aide des fonctions offertes par le systeme de gestion de base de donnees 
relationnelle ou SGBDR, utilise" pour la gestion de la base de donnees 2. 

Ces fonctions comprennent au minimum une fonction d'ecriture ou de 
creation d'un ensemble de donnees simples dans une table, une fonction de lecture 
d'un ensemble de donnees simples depuis une table, une fonction de suppression d'un 
25 ensemble d'une table, et une fonction de recherche d'un ensemble par son contenu, la 
fonction de modification d'un ensemble pouvant etre assimilee, pour la simplicite de 
• l'expose, a une lecture de l'ensemble suivie d'une ecriture de l'ensemble modifie. Par 
consequent, cette fonction ne sera pas decrite davantage. 

Dans ce qui suit, on va comparer les performances, en termes de nombres 
30 d'ensembles de donnees echanges avec la base de donnees 2, respectivement pour la 
technique anterieure et le procede de l'invention. 

En se referant a la figure 3, dans la technique anterieure, la base de donnees 
2 comporte une table principale 3 stockant les ensembles 31 de donnees simples en 
nombre fixe "nom" 12, "telephone" 13 et "telecopie" 14, et cette table principale est 
35 en relation avec deux tables annexes 4 et 5 contenant les ensembles 41 et 51 de 
donnees simples en nombre variable, respectivement les ensembles 41 constitues des 
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donnees simples "rue" 15 et "ville" 16 pour la table annexe 4, et les ensembles 51 
constitues de la donnee "contact" 17 pour la table annexe 5. 

De facon classique, une donnee ^identification unique "cle" 11, presente 
dans les ensembles 31, 41 et 51 respectivement stockes dans les tables 3, 4 et 5, est 
5 utilisee pour mettre en relation, c'est-a-dire faire se referencer, la table principale 3 et 
les tables annexes 4 et 5. 

1 °/ Ecriture d'un objet 6 dans la base de donnees 2 

L'ecriture, ou creation, d'un objet identifie par une valeur unique telle que 
1234 et comportant les donnees simples en nombre fixe "nom" 12, "telephone" 13, 
10 "ideeopie" 14, associees aux donnees simples "rue" 15, "ville" 16 et "contact" 17 en 
nombre variable, comportera classiquement les etapes suivantes : 

- ecriture de l'ensemble principal 31 constitue des donnees simples "cle" 
1 1. "nom" 12, "telephone" 13 et "telecopie" 14 dans la table 3 a l'aide de 
la fonction correspondante du SGBDR, en initialisant la donnee "cle" 1 1 
15 a la valeur 1234 ; cela pourra etre realise, par exemple, a l'aide d'une 

instruction SQL telle que : 

INSERT INTO "EntreeAnnuaire_main" (cle, nom, telephone, telecopie) 
VALUES (1234, "OTOOBE", "+33(0)1 44 34 85 03", "+33(0)1 44 34 85 
01") 

20 - ecriture de deux ensembles 41 constitues des donnees simples en nombre 

variable 15 et 16 a l'aide de la fonction correspondante du SGBDR, en 
initialisant dans chacun la donnee "cle" 11 a la valeur 1234, c'est-a-dire, 
ecriture des deux ensembles 41, et 41 2 constitues respectivement des 
donnees simples "cle" 11, "rue" 15,, "ville" 16, d'une part, etdes donnees 

25 simples "cle" 11, "rue" 15 2 , "ville" 16 2 d'autre part ; cela pourra etre 

realise, par exemple, par les instructions SQL : 

INSERT INTO "EntreeAnnuaire_l " (cle, rue, ville) VALUES (1234, 
"3bis, rue du Docteur-Foucault", "92000 NANTERRE") 
et : 

30 INSERT INTO "EntreeAnnuaire_l " (cle, rue, ville) VALUES (1234, "34, 

bd Haussmann", "75009 PARIS") 
- ecriture de trois ensembles 51 a l'aide de la fonction correspondante du 

SGBDR, en initialisant la donnee "cle" 11 a la valeur 1234, c'est-a-dire, 

ecriture des trois ensembles 51,, 51 2 et 51 3 constitues respectivement des 
35 donnees simples "cle" 11 et "contact" 17, pour le premier, des donnees 

simples "cle" 11 et "contact" 17 2 pour le second, et "cle" 11 et "contact" 
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17] pour le troisieme; cela pourra etre realise, par exemple, par les 
instructions SQL : 

INSERT INTO "EntreeAnnuaire_2" (cle, contact) VALUES (1234, "M. 
Laurent QUEREL") 

5 INSERT INTO "EntreeAnnuaire_2" (cle, contact) VALUES (1234, "M. 

Jean-Francois QUENTIN") 
et: 

INSERT INTO "Entree Annuaire_2" (cle, contact) VALUES (1234, "M. 
Gilles ANDRE") 

10 On constate que, dans la technique anterieure, on effectue done une 

operation d'ecriture pour stacker l'ensemble 31, deux operations d'ecriture pour 
stocker les ensembles 41, et trois ecritures pour stocker les ensembles 51, soit un 
total de six ecritures pour stocker l'ensemble des donnees correspondent a l'objet a 
stocker 6. 

15 2°/ Lecture d'un objet 6 dans la base de donnees 2 

La lecture d'un objet 6, ayant pour donnee unique "cle" 11 une valeur 
donnee telle que 1234, et comportant les donnees simples en nombre fixe "nom" 12, 
"telephone" 13, "telecopie" 14, associees aux donnees simples "rue" 15, "ville" 16 et 
"contact" 1 7 en nombre variable, se fera classiquement par les etapes suivantes : 
20 - lecture, a l'aide de la fonction correspondante du SGBDR, de l'ensemble 

principal 31, constitue des donnees simples "cle" 11, "nom" 12, 
"telephone" 13 et "telecopie" 14, dont la donnee "cle" 11 a la valeur 
donnee 1234 ; cela pourra etre realise, par exemple, a l'aide de 
l'instruction SQL : 

25 SELECT * FROM "EntreeAnnuaire_main" WHERE cle=1234 

- lecture, l'aide de la fonction correspondante du SGBDR, de tous les 
ensembles 41 de la table 4 comportant la valeur 1234 dans leur donnee 
"cle" 11, e'est-a-dire, lecture des deux ensembles 41 x et 41 2 constitues 
respectivement des donnees simples "cle" 11, "rue" 15i, "ville" 16i d'une 
30 part, et des donnees simples "cle" 11, "rue" 152, "ville" I62 d'autre part ; 

cela pourra etre obtenu, par exemple, a l'aide de l'instruction SQL : 
SELECT * FROM "EntreeAnnuaire_l" WHERE cle=1234 
cette instruction retrouvera alors les deux ensembles de donnees 41] et 
41 2 ; 

35 - lecture des ensembles 51 a l'aide de la fonction correspondante du 

SGBDR, en relisant tous les ensembles 51 de la table 5 comportant la 
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valeur donnee 1234 dans leur donnee "cle" 11, c'est-a-dire, lecture des 
trois ensembles 51 t , 51 2 et 51 3 constitues respectivement des donnees 
simples "cle" 11 et "contact" ll\ pour le premier, des donnees simples 
"cle" 1 1 et "contact" 17 2 pour le second, et "cle" 1 1 et "contact" 17i pour 
5 le troisieme; cela pourra etre obtenu, par exemple, a l'aide de 

rinstruction SQL : 

SELECT * FROM "EntreeAnnuaire_2" WHERE cle=1234 

cette instruction retrouvera alors les trois ensembles de donnees 5 1 1 , 5 1 2 

et51 3 . 

10 De meme que pour l'operation d'ecriture, on constate que, dans la technique 

anterieure, on effectue done au total de six operations de lecture d'ensemble de 
donnees dans les tables 3, 4 et 5 pour relire l'ensemble des donnees correspondant a 
l'objet 6 a relire. 

3°/ Suppression d'un objet 6 dans la base de donnees 2 

15 La suppression d'un objet, constitue des donnees simples "cle" 11, "nom" 

12, "telephone" 13 et "telecopie" 14, ayant pour donnee "cle" 11 une valeur donnee, 
par exemple 1234, et comportant les donnees simples en nombre fixe "nom" 12, 
"telephone" 13, "telecopie" 14, associees aux donnees simples en nombre variable 
"rue" 15, "ville" 16 et "contact" 17, se composera classiquement des etapes 

20 suivantes : 

- suppression de l'ensemble principal 31 ayant pour donnee "cle" 11 la 
valeur donnee 1234 a l'aide de la fonction correspondante du SGBDR ; 
cela pourra etre realise, par exemple, a l'aide de rinstruction SQL : 
DELETE FROM "EntreeAnnuaire_main" WHERE cle=1234 

25 - suppression des ensembles 41 ayant comme donnee "cle" 11 la valeur 

donnee 1234 a l'aide de la fonction correspondante du SGBDR, c'est-a- 
dire, suppression des deux ensembles 41 1 et 41 2 constitues 
respectivement des donnees simples "cle" 11, "rue" 15i, "ville" 16i d'une 
part, et des donnees simples "cle" 11, "rue" 15 2 , "ville" 16 2 d'autre part ; 

30 cela pourra etre realise, par exemple, a l'aide de rinstruction SQL : 

DELETE FROM "EntreeAnnuaire_l" WHERE cle=1234 

- suppression des ensembles 51 ayant comme donnee "cle" 11 la valeur 
donnee 1234 a l'aide de la fonction correspondante du SGBDR, c'est-a- 
dire, suppression des trois ensembles 51 1, 51 2 et 5h constitues 

35 respectivement des donnees simples "cle" 11 et "contact" 17i pour le 

premier, des donnees simples "cle" 11 et "contact" 17 2 pour le second, et 
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"cle" 11 et "contact" 17 3 pour le troisieme ; cela pourra etre realise, par 
exemple, a l'aide de l'instruction SQL : 
DELETE FROM "EntreeAnnuaire_2" WHERE cle=l 234 
De meme que pour les operations d'ecriture ou de lecture, on constate que, 
5 dans la technique anterieure, on effectue au total de six operations de suppression 
d'ensemble de donnees dans les tables 3, 4, et 5 pour supprimer l'ensemble des 
donnees correspondant a l'objet 6 a supprimer. 

4°/ Recherche d'un objet 6 dans la base de donnees 2 

Toujours dans la technique anterieure, la recherche d'un objet ayant, par 
10 exemple, pour donnee 12 "nom" la valeur "OTOOBE", et comportant un ensemble 
31 de donnees simples en nombre fixe "nom" 12, "telephone" 13, "telecopie" 14 
ax^K-iees aux donnees simples "rue" 15, "ville" 16 et "contact" 17 presentes dans les 
ensembles 41 et 51, sera constituee classiquement des etapes suivantes : 

- recherche, a l'aide de la fonction correspondante du SGBDR, de 
15 l'ensemble principal 31, constitue des donnees simples "cle" 11, "nom" 

1 2. "telephone" 13 et "telecopie" 14, dont la donnee 12 "nom" possede la 
valeur "OTOOBE" donnee ; cela pourra 6tre realise, par exemple, a l'aide 
de l'instruction SQL : 

SELECT * FROM "EntreeAnnuaire_main" WHERE nom="OTOOBE" 

20 - lecture, a l'aide de la fonction correspondante du SGBDR, de tous les 

ensembles 41 de la table 4 ayant, dans leur donnee "cle" 11, la valeur 
contenue dans la donnee "cle" 11 de l'ensemble 31 venant d'etre retrouve 
dans la table 3, c'est-a-dire, lecture des deux ensembles 41 1 et 41 2 
constitues respectivement des donnees simples "cle" 11, "rue" 15i, "ville" 

25 16i d'une part, et des donnees simples "cle" 11, "rue" 15 2 , "ville" 16 2 

d'autre part ; en supposant que la valeur contenue dans la donnee "cle" 1 1 
de l'ensemble 31 retrouve precedemment soit egale a 1234, cela pourra 
etre obtenu, par exemple, a l'aide de l'instruction SQL : 
SELECT * FROM "EntreeAnnuaire_l " WHERE cle=1234 

30 - lecture, a l'aide de la fonction correspondante du SGBDR, de tous les 

ensembles 51 de la table 5 ayant dans leur donnee "cle" 11, la valeur 
contenue dans la donnee "cle" 11 de l'ensemble 31 venant d'etre retrouve 
dans la table 3, c'est-a-dire, lecture des trois ensembles 51 1, 51 2 et 51 3 
constitues respectivement des donnees simples "cle" 11 et "contact" 17! 

35 pour le premier, des donnees simples "cle" 11 et "contact" 17 2 pour le 

second, et "cle" 11 et "contact" 17i pour le troisieme ; en supposant 



WO 02/03245 



PCT/FROO/01902 



25 

toujours que la valeur contenue dans la donnee 1 "cle" de l'ensemble 31 
retrouve soit egale a 1234, cela pourra etre obtenu, par exemple, a l'aide 
de l'instruction SQL : 

SELECT * FROM "EntreeAnnuaire_2" WHERE cle=1234 
5 De meme que pour les operations d'ecriture, de lecture ou de suppression, on 

constate que, dans la technique anterieure, on relit au total de six ensembles de 
donnees depuis les tables 3, 4 et 5 pour retrouver rensemble des donnees 
correspondant a l'objet 6 recherchd 

En se referant maintenant a la figure 2, dans le procede de l'invention, la 

10 base de donnees 2 comporte une table principale 3 stockant les ensembles 31 de 
donnees simples en nombre fixe "cle" 11, "nom" 12, "telephone" 13 et "telecopie" 14, 
et cette table principale est en relation avec une unique table annexe 7 contenant les 
ensembles 71 de donnees simples en nombre variable, constitues des donnees 
simples "contact" 17. De facon classique, une donnee d'identification unique "cle" 

15 11, presente dans les ensembles 31 et 71 respectivement stockes dans les tables 3 et 
7, est utilisee pour mettre en relation, c'est-a-dire faire se references la table 
principale 3 et la table annexe 7, et pour identifier de facon unique un objet 6 dans la 
base de donnees 2. 

1 °/ Ecriture d'un objet 6 dans la base de donnees 2 

20 L'ecriture, ou creation, d'un objet identifie par une valeur unique telle que 

1234 et comportant les donnees simples en nombre fixe "nom" 12, "telephone" 13, 
"telecopie" 14, associees aux donnees simples "rue" 15, "yille" 16 et "contact" 17 en 
nombre variable, comportera, dans le procede de 1'invention, les etapes suivantes : 

- ecriture de l'ensemble d'informations principal 31, constitue des donnees 
25 simples "cle" 1 1, "nom" 12, "telephone" 13 et "telecopie" 14, a l'aide de 

la primitive adequate du SGBDR, ce qui conduit a une operation 
d'ecriture pour cet ensemble 31 ; en supposant toujours que la valeur 
pour la donnee "cle" 1 1 soit 1234, cela pourra etre realise a l'aide d'une 
instruction SQL telle que : 
30 INSERT INTO "EntreeAnnuaire_main" (cle, nom, telephone, telecopie) 

VALUES (1234, "OTOOBE", "+33(0)1 44 34 85 03", "+33(0)1 44 34 85 

01") 

- stockage de la valeur 1234 dans les donnees "cle" 11 des trois ensembles 
de donnees simples 71 1, 71 2 , 71 3, stockage de la premiere donnee "rue" 

35 dans la donnee 15i de l'ensemble 71 1 de la table 7, stockage de la 

premiere donnee "ville" dans la donnee I61 de l'ensemble 71 1, stockage 
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de seconde donnee "rue" dans la donnee 15 2 de l'ensemble 71 2 , stockage 
de la seconde donnee "ville" dans la donnee 16 2 de l'ensemble 71 2, 
stockage de la premiere donnee "contact" dans la donnee 17i de 
l'ensemble 71 1, stockage de la seconde donnee "contact" dans la donnee 
17 2 de l'ensemble 71 2 , et stockage de la troisieme donnee "contact" dans 
la donnee 1 73 de l'ensemble 7 1 3 ; 

- initialisation de la donnee 20] a la valeur booleenne VRAI puisque les 
donnees simples "rue" 15i et "ville" I61 correspondantes sont presentes 
dans l'ensemble 71 1, initialisation de la donnee 21 1 a la valeur VRAI 
puisque la donnee "contact" 17i correspondante est presente dans 
l'ensemble 71 1, initialisation de la donnee 20 2 a la valeur VRAI puisque 
les donnees simples "rue" 15 2 et "ville" 162 correspondantes sont 
presentes dans l'ensemble 71 2, et initialisation de la donnee 21 2 a la 
valeur VRAI puisque la donnee "contact" 17 2 correspondante est 
presente dans l'ensemble 71 2 ; par contre, initialisation de la donnee 2O3 a 
la valeur FAUX puisque les donnees simples "rue" 15 3 et "ville" I63 
correspondantes sont absentes de l'ensemble 7I3 ; enfin, initialisation de 
la donnee 21 3 a la valeur VRAI puisque la donnee "contact" 17 3 
correspondante est bien presente dans l'ensemble 7h ; 

- ecriture les trois ensembles 71 1, 71 2 , 7I3 dans la base de donn6es 2 a 
l'aide d'instructions SQL telles que : 

INSERT INTO "EntreeAnnuaire_annex" (cle, presence_adresse, 

presence_contact, rue, ville, contact) VALUES (1234, TRUE, 
TRUE, "3bis, rue du Docteur-Foucault", "92000 NANTERRE", 
"M. Laurent QUEREL") 

INSERT INTO "EntreeAnnuaire_annex" (cle, presence_adresse, 

presence_contact, rue, ville, contact) VALUES (1234, TRUE, 
TRUE, "34, bd Haussmann", "75009 PARIS", "M. Jean-Francis 
QUENTIN") 

et: 

INSERT INTO "EntreeAnnuaire annex" (cle, presence_adresse, 

presence_contact, rue, ville, contact) VALUES (1234, FALSE, 
TRUE, "", "M. Gilles ANDRE") 
Ainsi, dans le precede selon l'invention, le nombre d'ecritures dans la base 
de donnees 2 est egal a quatre, au lieu de six dans la technique anterieure. 
2°/ Relecture d'un objet 6 dans la base de donnees 2 
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La lecture d'un objet 6, ayant pour donnee unique "cle" 11 une valeur 
donnee telle que 1234, et comportant les donnees simples en nombre fixe "nom" 12, 
"telephone" 13, "telecopie" 14, associees aux donnees simples "rue" 15, "ville" 16 et 
"contact" 17 en nombre variable, se fera, dans le procede de l'invention, par les etapes 
5 suivantes : 

- lecture, a l'aide de la fonction correspondante du SGBDR, de l'ensemble 
principal 31, constitue des donnees simples "cle" 11, "nom" 12, 
"telephone" 13 et "telecopie" 14, dont la donnee "cle" 11 a la valeur 
donnee 1234, ce qui conduit a une operation de lecture pour cet 
1 0 ensemble ; cette operation de lecture pourra etre realisee, par exemple, a 

l'aide de rinstruction SQL : 

SELECT * FROM "EntreeAnnuaire_main" WHERE cle=1234 

a l'aide des donnees presentes dans l'ensemble 31, le procede de 

l'invention restitue les donnees fixes de l'objet 6 ; plus precisement, le 

1 5 procede initialise la donnee en nombre fixe "nom" de l'objet 6 a l'aide de 

la donnee 12 presente dans l'ensemble 31 relu, il initialise la donnee en 
nombre fixe "telephone" de l'objet 6 a l'aide de la donnee 13 de ce meme 
ensemble, et il initialise la donnee en nombre fixe "telecopie" de l'objet 6 
a l'aide de la donnee 14 ; 

20 - lecture, dans la table 7, des ensembles 71 de cette table comportant la 

valeur 1234 dans leur donnee "cle" 11 ; cela pourra etre realise a l'aide 
d'un instruction SQL telle que : 

SELECT * FROM "EntreeAnnuaire_annex" WHERE cle=1234 
les trois ensembles de donnees 71 1, 71 2 , 71 3 sont ainsi relus, moyennant 
25 trois operations de lecture d'ensemble de donnees dans la base de donnees 

2; 

ainsi que cela a ete decrit precedemment, ces trois ensembles 71 j, 71 2 , 

7h de donnees sont chacun constitues de la donnee "cle" 1 1, des donnees 

simples en nombre variable "rue" 15, "ville" 16 et "contact" 17, et des 
30 donnees 20 et 21 indiquant respectivement la presence ou non de 

l'ensemble en nombre variable "rue", "ville" et de la donnee en nombre 

variable "contact" dans l'ensemble 71 concerne ; 
- reconstitution des donnees variables de l'objet 6 a l'aide des donnees 

presentes dans les ensembles de donnees 71 1, 71 2, 71 3 precedemment 
35 relus ; pour cela, le procede examine les donnees 20 et 21 dans chaque 

ensemble 71 1, 71 2 , 71 3 relu ; 
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plus precisement, si le contenu de la donnee booleenne 20 1 
contenue dans l'ensemble 71 1 est VRAI, cela signifie qu'il existait a 
l'origine un premier ensemble "rue", "ville" dans l'objet 6 stocke ; 
dans ce cas, le procecle selon 1'invention creera alors un premier 
sous-objet en nombre variable "adresse" dans l'objet 6 ; il remplira 
les donnees en nombre variable "rue" et "ville" de ce premier sous- 
objet avec respectivement les donnees 15j et 16i contenues dans 
l'ensemble 71 1 ; de meme, si le contenu de la donnee booleenne 21 1 
est vrai, cela signifie qu'il existait a l'origine une premiere donnee 
en nombre variable "contact" dans l'objet 6 ; dans ce cas, le procede 
de 1'invention creera une premiere donnee en nombre variable 
"contact" dans l'objet 6 ; 

en utilisant la meme demarche que ci-dessus, le procede de 
1'invention creera un second et un troisieme sous-objet "adresse" en 
nombre variable "rue", "ville" si les contenus des donnees 
booleennes 2O2 et 20 3 contenues respectivement dans les ensembles 
71 2 et 71 3 sont VRAI, et il initialiser les donnees "rue" et "ville" 
de ces second et troisieme sous-objets en nombre variable "adresse" 
avec les donnees respectivement 15 2 et I62 d'une part, et 15 3 et 16 3 
d'autre part respectivement contenues dans l'ensemble 71 2 et 
l'ensemble 71 3 ; 

de meme, le procede de 1'invention creera une seconde et une 
troisieme donnee en nombre variable I' contact" si les contenus des 
donnees booleennes 21 2 et 21 3 contenues respectivement dans les 
ensembles 71 2 et 71 3 sont VRAI, et il initialisera ces seconde et 
troisiemes donnees en nombre variable "contact" avec les donnees 
17 2 et 17 3 respectivement contenues dans l'ensemble 71 2 et 
l'ensemble 71 3 ; 

en supposant que les donnees relues proviennent de l'exemple 
d'ecriture d'objet 6 precedemment decrit, les donnees simples 20i, 
20 2 , 21 1, 21 2 et 21 3 seront a la valeur VRAI, tandis que la donnee 
20 3 sera a la valeur FAUX; dans ces conditions, le procede de 
1'invention reconstituera exactement deux ensembles de donnees 
"adresse" en nombre variable dans l'objet 6 relu, ainsi que trois 
donnees en nombre variable "contact" ; l'objet 6 d'origine sera done 
parfaitement reconstitue. 
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Pour relire l'objet 6, le precede effectue done au total trois operations de 
lecture d'ensembles de donnees dans la base de donnees 2, contre six pour la 
technique anterieure. 

3°/ Suppression d'objet 6 dans la base de donnees 2 
5 La suppression d'un objet ayant pour donnee "cle" 1 1 une valeur donnee, par 

exemple 1234, et comportant les donnees simples en nombre fixe "nom" 12, 
"telephone" 13, "telecopie" 14, associees aux donnees simples en nombre variable 
"rue" 15, "ville" 16 et "contact" 17, se composera, dans le precede de l'invention, des 
etapes suivantes : 

10 - suppression de l'ensemble principal 31, constitue des donnees simples 

"cle" 11, "nom" 12, "telephone" 13 et "telecopie" 14, ayant pour donnee 
"cle" 1 1 la valeur donnee 1234, a l'aide de la fonction correspondante du 
SGBDR ; cela pourra etre realise, par exemple, a l'aide de rinstruction 
SQL: 

1 5 DELETE FROM "Entree Annuaire_main" WHERE cle=l 234 

- suppression de l'ensemble annexe 71, ayant pour donnee "cle" 11 la 
valeur donnee 1234, a l'aide de la fonction correspondante du SGBDR ; 
cela pourra etre realise, par exemple, a l'aide de rinstruction SQL : 
DELETE FROM "Entree Annuaire_annex" WHERE cle=1234 

20 A nouveau, le nombre d'operations de suppression d'ensembles de donnees 

par le SGBDR s'eleve a un total de quatre dans le precede de l'invention, contre six 
dans la technique anterieure. 

4°/ Recherche d'un objet 6 dans la base de donnees 2 

- recherche, a l'aide de la fonction correspondante du SGBDR, de 
25 l'ensemble principal 31, constitue des donnees simples "cle" 11, "nom" 

12, "telephone" 13 et "telecopie" 14, dont la donnee 12 "nom" possede la 
valeur "OTOOBE" donnee ; cela pourra etre realise, par exemple, a l'aide 
de rinstruction SQL : 

SELECT * FROM "EntreeAnnuaire_main" WHERE nom="OTOOBE" 
30 - lecture, a l'aide de la fonction correspondante du SGBDR de tous les 

ensembles 71 de la table 7 ayant, dans leur donnee "cle" 11, la valeur 
contenue dans la donnee "cle" 11 de l'ensemble 31 venant d'etre retrouve 
dans la table 3, e'est-a-dire, lecture des trois ensembles 71 i, 71 2 et 71 3 
ayant la structure de donnees precedemment decrite ; en supposant que la 
35 valeur contenue dans la donnee "cle" 11 de l'ensemble 31 retrouve 
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precedemment soit egale a 1234, cela pourra 6tre obtenu, par exemple, a 
l'aide de l'instruction SQL : 

SELECT * FROM "EntreeAnnuaire_annex" WHERE cle=1234 
- reconstitution des donnees ou des sous-objets en nombre variable de 
5 l'objet 6 a relire a l'aide des donnees contenues dans les trois sous- 

ensembles relecture ; cette reconstitution est identique a celle decrite au 
paragraphe 2°/ ci-dessus ; en consequence, elle ne sera pas decrite plus en 
detail. 

A nouveau, le nombre d'operations de recherche d'ensembles de donnees par 
10 le SGBDR s'eleve a un total de quatre dans le procede de l'invention, contre six dans 
la technique anterieure. 

Ainsi, dans les quatre operations de base effectuees par un SGBDR, 
rutilisation du proced6 de Tinvention permet une reduction d'un tiers du nombre 
d'operations d'ensembles de donnees dans tous les cas. L'exemple presente ci-dessus, 
1 5 volontairement simple pour des raisons de clarte de l'expose, ne rend pas 
necessairement bien compte des gains tres importants que peut apporter le procede 
dans un cas pratique comportant un nombre tables en relation beaucoup plus 
important. 

Dans un cadre plus general, on designe, dans ce qui suit, par N a le nombre 
20 de tables annexes Tj, par N p le nombre total d'ensembles principaux 3 1 dans la table 
principale 3, et par K,y pour i variant de 1 a N a , le nombre total d'ensembles de 
donnees presents dans une table annexe T;. 

Avec ces conventions, dans la technique anterieure, le nombre moyen 
d'operations pour effectuer une entree-sortie concernant un objet 6 dans une table T ; 
25 donnee sera, en moyenne, egal a K f /N a , et le total general pour une entree-sortie 
complete comprenant l'ensemble principal 31 et les N a ensembles de donnees 
presents dans les N a tables annexes Tj sera done egal a : 

.14^=1 + J Kj/Np 
i=i 

30 Dans le cas du procede de la presente invention, le nombre d'entrees-sorties 

necessaire pour obtenir les ensembles de donnees contenus dans Tunique table 
annexe sera done egal en moyenne a Max (Ki)/N p , du fait que l'unique table annexe 
comporte un nombre d'ensembles egal au maximum des nombres d'ensembles 
presents dans les ensembles d'ensembles en relation ; par consequent, le total general 
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pour une entree-sortie complete comprenant Tensemble principal 31 et les ensembles 
de donnees contenus dans I'unique table annexe sera done egal a : 

N proc =l + Isgx(Ki)/N p 

5 On voit que sauf circonstance tres exceptionnelle, le nombre moyen 

d'entrees-sorties N proc avec le procede de la presente invention sera toujours tres 
inferieur au nombre moyen d'entrees-sorties N ant sans ce procede. Dans le cas 
favorable, mais relativement frequent, ou le nombre d'ensembles de donnees est 
sensiblement le meme dans les diverses tables annexes, le procede selon l'invention 
1 0 permet un gain en performances atteignant un facteur egal au rapport N proc /Nant 5 e'est- 
a-dire : 

l+Max(Ki)/N P 



1+ Z Ki/Np 



soit en utilisant l'hypothese que les divers K s sont sensiblement egaux entre eux, et, 
1 5 done au maximum d'entre eux : 

l + ML(Ki)/N P 



l + N a xMax(Ki)/N P 



soit en negligeant 1 devant Max (Ki)/N p , un rapport de valeur 1/N a , ce constitue une 
diminution tres importante du nombre d'entrees-sorties des que le nombre de tables 
annexes augmente. 

20 Ce procede est done particulierement souhaitable dans toutes les 

applications de bases de donnees relationnelles dans lesquelles les performances 
constituent un facteur critique, telles que les applications temps reel ou celles 
utilisant des serveurs de bases de donnees tres sollicites, comrne ceux qui se 
rencontrent dans les reservations centralisees par un reseau, ou dans la consultation 

25 de bases de donnees via le reseau mondial Internet. 

En outre, l'utilisation du langage XML pour representer les objets stockes 
dans la base de donnees 2 permet l'utilisation de patrons d'objets XML pour filtrer 
certaines donnees des objets 6 entrants et sortants de la base de donnees 2. -Ainsi, 
dans le mode de realisation prefere de la presente invention, des patrons d'objets 
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XML 61 , collectivement denommes I/O Format et conformes a une description XML 
Schema, sont utilises pour realiser un tel filtrage. 

Plus precisement, ces patrons d'objets XML I/O Format 61 supprimeront 
certaines donnees sensibles des objets entrants, comme des donnees concernant la 
5 validite des donnees contenues dans un objet 6, de facon a ce que ces donnees 
sensibles ne puissent etre, en tout etat de cause, modifiees depuis le reseau 60, et a ce 
que leur modification ne puisse etre effectuee que par un operateur intervenant 
directement sur 1'ordinateur serveur 1. 

De meme, les patrons d'objets XML I/O Format 61, en fonction des donnees 

10 effectivement utilisees par un utilisateur sur le reseau 60, supprimeront dans les 
donnees d'un objet 6 transmises sur le reseau 60 les donnees qui ne seraient pas 
utilisees par ledit utilisateur. Compte-tenu de ce que, dans la pratique, les donnees 
transmises pour un objet 6 ne represented habituellement qu'une faible partie de 
l'ensemble des donnees de cet objet, ce procede permet une reduction substantielle du 

15 volume des donnees transmises par 1'ordinateur serveur 1, ce qui est particulierement 
interessant dans le cas d'ordinateur serveur 1 tres charge, tels que ceux qui se 
rencontrent dans l'lnternet. 

En outre, ce proceed permet de prendre en compte differents niveaux de 
securite attaches aux utilisateurs se connectant via le reseau 60, en associant a chaque 

20 niveau de securite un patron eliminant des donnees transmises a l'utilisateur les 
donnees non autorisees pour le niveau de securite de l'utilisateur. 

En outre, du fait que ce procede garantit que seules les donnees conformes 
au patron d'objet I/O Format 61 utilise seront transmises, il n'y aura pas lieu de 
demander la restitution par la base de donnees 2, des donnees eliminees par le patron 

25 d'objet I/O Format 61 utilise, et ainsi les donnees apparaissant dans les requetes SQL 
"SELECT" effectuees par le moteur COS Engine pourront etre limitees aux seules 
•donnees transmises, ce qui diminuera de fa9on toute aussi sensible' la charge 
d'entrees-sorties dans la base de donnees 2 dans 1'ordinateur serveur 1. 

Ce procede permet de focaliser la requete sur les tables de la base de 

30 donnees 2 et les donnees dans ces tables 3 et 7 qui sont effectivement utilisees dans 
la requete d'un utilisateur. Ainsi, dans le cas ou aucune donnee de la table annexe 7 
n'est utilisee dans la requete, le procede n'accedera pas a cette table 7 pour la requete, 
ce qui, a nouveau, permettra d'ameliorer sensiblement les performances de 
1'ordinateur serveur 1 mettant en oeuvre le procede de l'invention. 

35 Ainsi, l'utilisation du format XML et d'un patron d'objet au format XML 

permet d'imposer des regies de securite sur les donnees entrantes, de limiter 
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l'utilisation de la base passante du reseau 60 aux seules donnees necessaires et de 
diminuer en due proportion le volume des donnees echangees avec la base de 
donnees 2. 

Dans le mode de realisation decrit ci-dessus, la donnee "cle" 11, identifiant 
5 de facon unique un objet 6, a ete indiquee, pour des raisons de simplicite de l'expose, 
comme etant geree de facon explicite par le procede de 1'invention. Toutefois, cette 
technique explicite n'est en aucune maniere obligatoire, et elle peut parfaitement 6tre 
remplacee par toute autre technique equivalente pouvant etre offerte par le SGBDR 
utilise. 

1 () De raeme, cette donnee "cle" 1 1 a ete decrite comme etant constituee d'un 

scul nombre entier, mais elle peut tout aussi bien etre constituee de plusieurs parties. 
Par excmple, dans le mode de realisation prefere" de 1'invention, une donnee "cle" 11 
unique, appelee Object IDentifier ou ODD, est obtenue pour chaque objet 6 en 
concaienant une premiere partie constituee du nom logique du serveur 1 sur lequel 

15 reside la base de donnee 2, une seconde partie constitute du numero de la table 
principalc 3 dans la base de donnee 2, et une troisieme partie constitute du numero 
d'enrcgistrcment de l'ensemble de donnees principal 3 1 dans ladite table 3. 

Le nom logique du serveur 1 etant unique sur le reseau 60, la base de 
donnees 2 etant unique sur le serveur 1 ou elle est stockee, le numero de la table 3 

20 etant unique dans la base de donnees et le numero d'enregistrement de l"ensemble de 
donnees principal 3 1 etant unique dans la table 3, l'OID 1 1 ainsi obtenu pour un objet 
6 sera done unique parmi l'ensemble des OED identifiant les objets 6 accessibles via 
le reseau 60. En outre, ce type de donnee "cle" 1 1 presentera rinteret de permettre de 
localiser precisement le lieu de stockage d'un objet 6 quelconque sur la seule base de 

25 son OID 1 1 associe. 

Par ailleurs, dans l'exemple decrit ci-dessus, il a ete fait reference a une 
application de type annuaire, mais le procede de 1'invention est egalement utilise dans 
des application de type conferences ou publications. 

D'une fa9on generate, la description ci-dessus ne doit pas etre comprise 
30 comme reduisant en quoi que ce soit la portee de la presente invention telle que 
revendiquee dans les revendications annexees. 
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REVENDICATIONS 

1. Procede de stockage d'objets informationnels ou objets (6), dans une base de 
donnees relationnelle (2) stockee dans un ordinateur serveur (1), ladite base 
de donnees relationnelle (2) etant constituee de tables, chaque table etant 

5 constituee d'un tableau d'ensembles de donnees simples, lesdits ensembles 

ayant la meme structure de donnees dans une meme table, chaque donnee 
simple d'une table etant designee par un identifiant unique dans ladite table, 
un objet (6) etant constitue d'une ou plusieurs donnees simples pouvant etre 
stockees dans une table de ladite base de donnees (2), et/ou d'un ou plusieurs 

10 objets emboites dans ledit objet, ledit emboitement pouvant fitre realise sur 

un nombre quelconque de niveaux pour realiser un objet (6), un objet 
emboite ou une donnee simple etant dit localement en nombre fixe s'il ou 
elle apparait exactement une fois dans l'objet le ou la contenant 
imm&iiaternent et etant dit localement en nombre variable dans le cas 

15 contraire, une donnee simple apparaissant a un niveau quelconque dudit 

objet (6) etant dite globalement en nombre fixe si elle est localement en 
nombre fixe et si tous les objets la contenant sont localement en nombre 
fixe, une donnee simple apparaissant a un niveau quelconque dudit objet (6) 
6tant dite globalement en nombre variable si elle est localement en nombre 

20 variable ou si l'un quelconque des objets la contenant est localement en 

nombre variable, Iesdites donnees globalement en nombre fixe d'un objet a 
stocker (6) etant stockees dans un ensemble de donnees principal (31) stocke 
dans une table principale (3) de ladite base de donnees (2), Iesdites donnees 
simples globalement en nombre variable dudit objet a stocker (6) etant 

25 stockees dans une ou une ou plusieurs tables annexes (4, 5, 7) de ladite base 

de donnees (2), caracterise par le fait que, lorsqu'elles existent, les donnees 
simples globalement en nombre variable desdits objets (6) sont stockees 
dans une unique table annexe (7) de ladite base de donnees, le procede 
creant un ou plusieurs ensembles de donnees annexes (71) pour stocker 

30 Iesdites donnees simples globalement en nombre variable dans ladite unique 

table annexe (7). 

2. Procede selon la revendication 1, dans lequel chacun desdits un ou plusieurs 
ensembles annexes (71) eventuellement stockes dans ladite unique table 
annexe (7) comporte en outre un ensemble (72) d'indicateurs booleens, 

35 chaque indicateur booleen etant associe a une donnee particuliere desdites 

donnees simples globalement en nombre variable stockees dans ledit 
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ensemble annexe (71), ledit indicateur booleen indiquant si ladite donnee 
simple globalement en nombre variable associee est definie ou non dans 
ledit ensemble annexe (71). 

Precede selon la revendication 2, dans lequel certains desdits indicateurs 
booleens dudit ensemble (72) d'indicateurs booleens sont communs a 
plusieurs donnees simples globalement en nombre variable lorsque lesdites 
donnees simples sont localement en nombre fixe dans un meme objet les 
contenant immediatement. 

Precede selon l'une quelconque des revendications precedentes, dans lequel 
ledit ensemble principal (31) associe au dit objet (6) a stocker comporte une 
donnee (11) permettant d'identifier de facon unique ledit ensemble principal 
(31) dans ladite table principale (3). 

Precede selon la revendication 4, dans lequel ladite donnee unique (11) est 
unique dans ledit ordinateur serveur (1). 

6. Precede selon l'une des revendications 4 ou 5, dans lequel ladite donnee 
unique (11) stockee dans ledit ensemble principal (31) associe au dit objet 
(6) a stocker est en outre stockee dans chacun des ensembles annexes (71) 
associes au dit objet (6) a stocker, pour permettre la mise en relation dudit 
ensemble principal (3) et du ou desdits ensembles annexes (71) eventuels 
associes au dit objet (6) a stocker. 

7. Precede selon l'une quelconque des revendications 4 a 6, dans lequel ladite 
donnee unique (11) est constitute du nom logique de l'ordinateur serveur (1) 
sur ledit reseau (60), du numero de table de ladite table principale (3) dans 
ladite base de donnees (2) et du numero d'ensemble de donnees dudit 
ensemble principal (31) dans ladite table principale (3), ledit nom logique de 
l'ordinateur serveur (1) etant unique sur ledit reseau {60), ladite base de 
donnees (2) etant unique sur ledit ordinateur serveur (1), ledit numero de 
table de ladite table principale (3) etant unique dans ladite base de donnees 
(2) et ledit numero d'ensemble de donnees dudit ensemble principal (31) 
etant unique dans ladite table principale (3). 

8. Precede selon l'une quelconque des revendications precedentes, dans lequel 
deux objets (6) a stocker sont dits de meme type s'ils sont constitues de 
donnees simples et d'objet emboites de meme type, deux objets (6) de mSme 
type ayant en commun un meme identifiant et les donnees simples et/ou les 
objets emboites se correspondant a un niveau quelconque desdits objets (6) 
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de meme type ayant en commun un meme identifiant, unique dans l'objet les 
contenant irnmediatement. 

9. Procede selon la revendication 8, dans lequel le precede cree un identifiant 
global pour tous les objets (6) de meme type et pour toutes les donnees 

5 simples se correspondant a un niveau quelconque desdits objets (6) de 

meme type, ledit identifiant global etant ledit identifiant commun pour 
lesdits objets de meme type, et ledit identifiant global etant obtenu, pour 
chacune desdites donnees simples se correspondant, par la concatenation des 
identifiants, dans les objets les contenant immediatement, de tous les objets 
1 0 contenant ladite donnee simple, et de l'identifiant de ladite donnee simple 

dans l'objet la contenant immediatement. 

10. Procede selon la revendication 9, dans lequel le nombre de caracteres de 
l'identifiant global est tronque au nombre de caracteres permis par ladite 
base de donnees (2) pour l'identifiant d'une donnee stockee dans une table de 

15 ladite base de donnees (2). 

11. Procede selon la revendication 10, dans lequel une ambiguite pouvant 
apparaitre du fait de ladite troncature est resolue en effectuant les etapes 
consistant a : 

remplacer le dernier caractere alphabetique de l'identifiant global par le 
20 chiffre zero, ainsi que les eventuels chiffres le suivant ; 

- augmenter d'une unite le nombre constitue par l'ensemble des chiffres 

apparaissant a la fin dudit identifiant global jusqu'a ce que 1'ambiguTte 

disparaisse ou que les chiffres a la fin dudit identifiant global soient 

entierement constitues de chiffres neuf ; 
25 - repeter les etapes precedentes depuis le debut lorsque les chiffres 

apparaissant a la fin dudit identifiant global sont entierement constitues 

de chiffres neuf a Tissue de l'etape precedente. 

12. Procede selon l'un quelconques des revendications precedentes, dans lequel 
les objets (6) stockes dans la base de donnees (2) sont recus ou transmis par 

30 1'ordinateur serveur (1) via un reseau informatique (60) de type Internet. 

13. Procede selon l'une des quelconques des revendications precedentes, dans 
lequel les donnees simples constituant lesdits objets (6) stockes dans ladite 
base de donnees (2) sorit de type texte. 

14. Procede selon la revendication 13, dans lequel lesdites donnees simples de 
3 5 type texte sont des donnees ecrites en langage XML. 
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15. Procede selon la revendication 14, dans lequel lesdites donnees ecrites en 
langage XML sont conformes a une description (92) de type XML Schema. 

16. Procede selon la revendication 1 5, dans lequel un ensemble de donnees (95) 
au format XML est obtenu par une traduction automatique de ladite 

5 description (92), ledit ensemble de donnees (95) et un ensemble de donnees 

complementaire (96) etant a leur tour traduits automatiquement en langage 
SQL pour definir et gerer la structure de la base de donnees (2), et pour 
controler les echanges de donnees avec ladite base de donnees (2). 

17. Procede selon Tune quelconque des revendications 14 a 16, dans lequel une 
1 o partie des donnees simples des objets (6) recus par ledit reseau (60) de type 

Internet est supprimee a l'aide d'un patron, ou modele, d'objet (61) ecrit en 
langage XML, pour interdire la modification desdites donnees simples via 
ledit reseau (60). 

18. Procede selon l'une quelconque des revendications 14 a 17, dans lequel une 
1 5 partie des donnees simples des objets transmis via ledit reseau est supprimee 

a l'aide d'un patron d'objet (61) ecrit en langage XML pour limiter la 
transmission sur ledit reseau (60) a certaines donnees simples desdits objets 
(6). 

19. Procede selon la revendication 18, dans lequel la suppression de d'une partie 
20 des donnees simples contenues dans les objets (6) permet en outre 

d'optimiser les requetes a ladite base de donnees (2). 

20. Systeme de stockage d'objets informationnels ou objets (6), dans une base 
de donnees relationnelle (2) stockee par un ordinateur serveur (1), 
caracterise par le fait qu'il met en oeuvre le proc'ede selon l'une quelcbnques 

25 des revendications precedentes. 
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